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SIP-Based Messaging with S/MIME 
Abstract 


Mobile messaging applications used with the Session Initiation 
Protocol (SIP) commonly use some combination of the SIP MESSAGE 
method and the Message Session Relay Protocol (MSRP). While these 
provide mechanisms for hop-by-hop security, neither natively provides 
end-to-end protection. This document offers guidance on how to 
provide end-to-end authentication, integrity protection, and 
confidentiality using the Secure/Multipurpose Internet Mail 
Extensions (S/MIME). It updates and provides clarifications for RFCs 
3261, 3428, and 4975. 


Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 7841. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
https://www.rfc-editor.org/info/rfc8591. 
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1. Introduction 


Several mobile messaging systems use the Session Initiation Protocol 
(SIP) [RFC3261], typically as some combination of the SIP MESSAGE 
method [RFC3428] and the Message Session Relay Protocol (MSRP) 
[RFC4975]. For example, Voice over LTE (VoLTE) uses the SIP MESSAGE 
method to send Short Message Service (SMS) messages. The Open Mobile 
Alliance (OMA) Converged IP Messaging (CPM) system [CPM] uses the SIP 
MESSAGE method for short "pager mode" messages and uses MSRP for 
large messages and for sessions of messages. The Global System for 
Mobile Communications Association (GSMA) Rich Communication Services 
(RCS) uses CPM for messaging [RCS]. 


At the same time, organizations increasingly depend on mobile 
messaging systems to send notifications to their customers. Many of 
these notifications are security sensitive. For example, such 
notifications are commonly used for notice of financial transactions, 
notice of login or password change attempts, and the sending of 
two-factor authentication codes. 


Both SIP and MSRP can be used to transport any content using 
Multipurpose Internet Mail Extensions (MIME) formats. The SIP 
MESSAGE method is typically limited to short messages (under 

1300 octets for the MESSAGE request). MSRP can carry arbitrarily 
large messages and can break large messages into chunks. 


While both SIP and MSRP provide mechanisms for hop-by-hop security, 
neither provides native end-to-end protection. Instead, they depend 
on S/MIME [RFC8550] [RFC8551]. However, at the time of this writing, 
S/MIME is not in common use for SIP-based and MSRP-based messaging 
services. This document updates and clarifies RFCs 3261, 3428, and 
4975 in an attempt to make S/MIME for SIP and MSRP easier to 
implement and deploy in an interoperable fashion. 


This document updates RFCs 3261, 3428, and 4975 to update the 
cryptographic algorithm recommendations and the handling of S/MIME 
data objects. It updates RFC 3261 to allow S/MIME signed messages to 
be sent without embedded certificates in some situations. Finally, 
it updates RFCs 3261, 3428, and 4975 to clarify error-reporting 
requirements for certain situations. 


2. Terminology 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 


"OPTIONAL" in this document are to be interpreted as described in 
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 
capitals, as shown here. 
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3. 


Problem Statement and Scope 


This document discusses the use of S/MIME with SIP-based messaging. 
Other standardized messaging protocols exist, such as the Extensible 
Messaging and Presence Protocol (XMPP) [RFC6121]. Likewise, other 
end-to-end protection formats exist, such as JSON Web Signatures 
[RFC7515] and JSON Web Encryption [RFC7516]. 


This document focuses on SIP-based messaging because its use is 
becoming more common in mobile environments. It focuses on S/MIME, 
since several mobile operating systems already have S/MIME libraries 
installed. While there may also be value in specifying end-to-end 
security for other messaging and security mechanisms, it is out of 
Scope for this document. 


MSRP sessions are negotiated using the Session Description Protocol 
(SDP) [RFC4566] offer/answer mechanism [RFC3264] or similar 
mechanisms. This document assumes that SIP is used for the 
offer/answer exchange. However, the techniques should be adaptable 
to other signaling protocols. 


[RFC3261], [RFC3428], and [RFC4975] already describe the use of 
S/MIME. [RFC3853] updates SIP to support the Advanced Encryption 
Standard (AES). In aggregate, that guidance is incomplete, contains 


inconsistencies, and is still out of date in terms of supported and 
recommended algorithms. 


The guidance in RFC 3261 is based on an implicit assumption that 


S/MIME is being used to secure signaling applications. That advice 
is not entirely appropriate for messaging applications. For example, 
it assumes that message decryption always happens before the SIP 


transaction completes. 


This document offers normative updates and clarifications to the use 
of S/MIME with the SIP MESSAGE method and MSRP. It does not attempt 
to define a complete secure messaging system. Such a system would 
require considerable work around user enrollment, certificate and key 
generation and management, multi-party chats, device management, etc. 
While nothing herein should preclude thos fforts, they are out of 
Scope for this document. 


This document primarily covers the sending of single messages -- for 
example, "pager-mode messages" sent using the SIP MESSAGE method and 
"large messages" sent in MSRP. Techniques to use a common signing or 


encryption key across a session of messages are out of scope for this 
document. 
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Cryptographic algorithm requirements in this document are intended to 
supplement those already specified for SIP and MSRP. 


4. Applicability of S/MIME 


The Cryptographic Message Syntax (CMS) [RFC5652] is an encapsulation 
syntax that is used to digitally sign, digest, authenticate, or 
encrypt arbitrary message content. The CMS supports a variety of 
architectures for certificate-based key management, especially the 
one defined by the IETF PKIX (Public Key Infrastructure using X.509) 
Working Group [RFC5280]. The CMS values are generated using ASN.1 
[X680], using the Basic Encoding Rules (BER) and Distinguished 
Encoding Rules (DER) [X690]. 


The S/MIME Message Specification [RFC8551] defines MIME body parts 
based on the CMS. In this document, the application/pkcs7-mime media 
type is used to digitally sign an encapsulated body part, and it is 
also used to encrypt an encapsulated body part. 


4.1. Signed Messages 


While both SIP and MSRP require support for the multipart/signed 
format, the use of application/pkcs7-mime is RECOMMENDED for most 
Signed messages. Experience with the use of S/MIME in electronic 
mail has shown that multipart/signed bodies are at greater risk of 
"helpful" tampering by intermediaries, a common cause of signature 
validation failure. This risk is also present for messaging 
applications; for example, intermediaries might insert Instant 
Message Disposition Notification (IMDN) requests [RFC5438] into 
messages. (See Section 9.2.) The application/pkcs7-mime format is 
also more compact, which can be important for messaging applications, 
especially when using the SIP MESSAGE method. (See Section 7.1.) 

The use of multipart/signed may still make sense if the message needs 
to be readable by receiving agents that do not support S/MIME. 


When generating a signed message, sending User Agents (UAs) SHOULD 
follow the conventions specified in [RFC8551] for the 
application/pkcs7-mime media type with smime-type-signed-data. When 
validating a signed message, receiving UAs MUST follow the 
conventions specified in [RFC8551] for the application/pkcs7-mime 
media type with smime-type-signed-data. 
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Sending and receiving UAs MUST support the SHA-256 message digest 
algorithm [RFC5754]. For convenience, the SHA-256 algorithm 
identifier is repeated here: 


id-sha256 OBJECT IDENTIFIER ::= { 
joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 
csor(3) nistalgorithm(4) hashalgs(2) 1 ] 


Sending and receiving UAs MAY support other message digest 
algorithms. 


Sending and receiving UAs MUST support the Elliptic Curve Digital 
Signature Algorithm (ECDSA) using the NIST P-256 elliptic curve and 
the SHA-256 message digest algorithm [RFC5480] [RFC5753]. Sending 
and receiving UAs SHOULD support the Edwards-curve Digital Signature 
Algorithm (EdDSA) with curve25519 (Ed25519) [RFC8032] [RFC8419]. For 
convenience, the ECDSA with SHA-256 algorithm identifier, the object 
identifier for the well-known NIST P-256 elliptic curve, and the 
Ed25519 algorithm identifier are repeated here: 


ecdsa-with-SHA256 OBJECT IDENTIFIER ::= { 
iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures (4) 
ecdsa-with-SHA2(3) 2 ] 


-- Note: The NIST P-256 elliptic curve is also known as secp256rl. 


secp256rl OBJECT IDENTIFIER ::= { 
iso(1) member-body(2) us(840) ansi-X9-62(10045) curves (3) 
prime(1) 7 } 


id-Ed25519 OBJECT IDENTIFIER ::= { 
iso(1) identified-organization(3) thawte(101) 112 } 


4.2.  Encrypted Messages 


When generating an encrypted message, sending UAs MUST follow the 
conventions specified in [RFC8551] for the application/pkcs7-mime 
media type with smime-type-auth-enveloped-data. When decrypting a 
received message, receiving UAs MUST follow the conventions specified 
in [RFC8551] for the application/pkcs7-mime media type with 
smime-type-auth-enveloped-data. 
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Sending and receiving UAs MUST support the AES-128-GCM algorithm for 
content encryption [RFC5084]. For convenience, the AES-128-GCM 
algorithm identifier is repeated here: 


id-aes128-GCM OBJECT IDENTIFIER ::- { 
joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 
csor(3) nistAlgorithm(4) aes(1) 6 } 


Sending and receiving UAs MAY support other content-authenticated 
encryption algorithms. 


Sending and receiving UAs MUST support the AES-128-WRAP algorithm for 
encryption of one AES key with another AES key [RFC3565]. For 
convenience, the AES-128-WRAP algorithm identifier is repeated here: 


id-aes128-wrap OBJECT IDENTIFIER ::- { 
joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 
csor(3) nistAlgorithm(4) aes(1) 5 } 


Sending and receiving UAs MAY support other key-encryption 
algorithms. 


Symmetric key-encryption keys can be distributed before messages ar 
sent. If sending and receiving UAs support previously distributed 
key-encryption keys, then they MUST assign a KEKIdentifier [RFC5652] 
to the previously distributed symmetric key. 


Alternatively, a key agreement algorithm can be used to establish a 
single-use key-encryption key. If sending and receiving UAs support 
key agreement, then they MUST support the Elliptic Curve 
Diffie-Hellman (ECDH) algorithm using the NIST P-256 elliptic curve 
and the ANSI-X9.63-KDF key derivation function with the SHA-256 


message digest algorithm [RFC5753]. If sending and receiving UAs 
support key agreement, then they SHOULD support the ECDH algorithm 
using curve25519 (X25519) [RFC7748] [RFC8418]. For convenience, 


(1) the identifier for the ECDH algorithm using the ANSI-X9.63-KDF 
with the SHA-256 algorithm and (2) the identifier for the X25519 
algorithm are repeated her 


dhSinglePass-stdDH-sha256kdf-scheme OBJECT IDENTIFIER ::= { 
iso(1) identified-organization(3) certicom(132) 
Schemes (1) 11 1 } 


id-X25519 OBJECT IDENTIFIER ::- { 
iso(1) identified-organization(3) thawte(101) 110 } 
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4.3. Signed and Encrypted Messages 


RFC 3261, Section 23.2 says that when a User Agent Client (UAC) sends 
signed and encrypted data, it "SHOULD" send an EnvelopedData object 
encapsulated within a SignedData message. That essentially says that 
one should encrypt first, then sign. This document updates RFC 3261 
to say that, when sending signed and encrypted user content in a SIP 
MESSAGE request, the sending UAs MUST sign the message first, and 
then encrypt it. That is, it must send the SignedData object inside 


an AuthEnvelopedData object. For interoperability reasons, 
recipients SHOULD accept messages signed and encrypted in either 
order. 


4.4. Certificate Handling 


Sending and receiving UAs MUST follow the S/MIME certificate-handling 
procedures [RFC8550], with a few exceptions detailed below. 


4.4.1. Subject Alternative Name 


In both SIP and MSRP, the identity of the sender of a message is 
typically expressed as a SIP URI. 


The subject alternative name extension is used as the preferred means 
to convey the SIP URI of the subject of a certificate. Any SIP URI 
present MUST be encoded using the uniformResourceIdentifier CHOICE of 
the GeneralName type as described in [RFC5280], Section 4.2.1.6. 
Since the SubjectAltName type is a SEQUENCE OF GeneralName, multiple 
URIs MAY be present. 


Other methods of identifying a certificate subject MAY be used. 
4.4.2. Certificate Validation 

When validating a certificate, receiving UAs MUST support the ECDSA 

using the NIST P-256 elliptic curve and the SHA-256 message digest 

algorithm [RFC5480]. 


Sending and receiving UAs MAY support other digital signature 
algorithms for certificate validation. 


5. Transfer Encoding 


SIP and MSRP UAs are always capable of receiving binary data. Inner 
S/MIME entities do not require base64 encoding [RFC4648]. 


Both SIP and MSRP provide 8-bit safe transport channels; base64 
encoding is not generally needed for the outer S/MIME entities. 
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However, if there is a chance a message might cross a 7-bit transport 


(for example, gateways that convert to a 7-bit transport for 
intermediate transfer), base64 encoding may be needed for the outer 
entity. 


6. User Agent Capabilities 


Messaging UAs may implement a subset of S/MIME capabilities. Even 
when implemented, some features may not be available due to 
configuration. For example, UAs that do not have user certificates 
cannot sign messages on behalf of the user or decrypt encrypted 
messages sent to the user. At a minimum, a UA that supports S/MIME 
MUST be able to validate a signed message. 


End-user certificates have long been a barrier to large-scale S/MIME 
deployment. But since UAs can validate signatures even without local 
certificates, the use case of organizations sending secure 
notifications to their users becomes a sort of "low-hanging fruit". 
That being said, the signed-notification use case still requires 
shared trust anchors. 


SIP and MSRP UAs advertise their level of support for S/MIME by 
indicating their capability to receive the "application/pkcs7-mime" 
media type. 


The fact that a UA indicates support for the "multipart/signed" media 
type does not necessarily imply support for S/MIME. The UA might 
just be able to display clear-signed content without validating the 
signature. UAs that wish to indicate the ability to validate 
Signatures for clear-signed messages MUST also indicate support for 
"application/pkcs7-signature". 


A UA can indicate that it can receive all smime-types by advertising 


"application/pkcs7-mime" with no parameters. If a UA does not accept 
all smime-types, it advertises the media type with the appropriate 
parameters. If more than one smime-type is supported, the UA 


includes a separate instance of the media-type string, appropriately 
parameterized, for each. 


For example, a UA that can only receive signed-data would advertise 
"application/pkcs7-mime; smime-type-signed-data". 


SIP signaling can fork to multiple destinations for a given Address 
of Record (AOR). A user might have multiple UAs with different 
capabilities; the capabilities remembered from an interaction with 
one such UA might not apply to another. (See Section 7.2.) 
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UAs can also advertise or discover S/MIME using out-of-band 
mechanisms. Such mechanisms are beyond the scope of this document. 


7. Using S/MIME with the SIP MESSAGE Method 


The use of S/MIME with the SIP MESSAGE method is described in 

Section 11.3 of [RFC3428], and for SIP in general in Section 23 of 
[RFC3261]. This section and its child sections offer clarifications 
for the use of S/MIME with the SIP MESSAGE method, along with related 
updates to RFCs 3261 and 3428. 


Tib Size Limit 


SIP MESSAGE requests are typically limited to 1300 octets. That 
limit applies to th ntire message, including both SIP header fields 
and the message content. This is due to the potential for 
fragmentation of larger requests sent over UDP. In general, it is 
hard to be sure that no proxy or other intermediary will forward a 
SIP request over UDP somewhere along the path. Therefore, S/MIME 
messages sent using the SIP MESSAGE method should be kept as small as 
possible. Messages that will not fit within the limit can be sent 
using MSRP. 


Section 23.2 of [RFC3261] requires that a SignedData message contain 
a certificate to be used to validate the signature. In order to 
reduce the message size, this document updates that text to say that 
a SignedData message sent in a SIP MESSAGE request SHOULD contain the 
certificate but MAY omit it if the sender has reason to believe that 
the recipient (1) already has the certificate in its keychain or 

(2) has some other method of accessing the certificate. 


7.2. SIP User Agent Capabilities 


SIP UAs can theoretically indicate support for S/MIME by including 
the appropriate media type or types in the SIP Accept header field in 
a response to an OPTIONS request, or in a 415 (Unsupported Media 
Type) response to a SIP request that contained an unsupported media 
type in the body. Unfortunately, this approach may not be reliable 
in the general case. In the case where a downstream SIP proxy forks 
an OPTIONS or other non-INVITE request to multiple User Agent Servers 
(UASS), that proxy will only forward the "best" response. If the 
recipient has multiple devices, the sender may only learn the 
capabilities of the device that sent the forwarded response. Blindly 
trusting this information could result in S/MIME messages being sent 
to UAs that do not support it, which would be at best confusing and 
at worst misleading to the recipient. 
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8. 


UAs might be able to use the UA capabilities framework [RFC3840] to 
indicate support. However, doing so would require the registration 
of one or more media feature tags with IANA. 


UAs MAY use other out-of-band methods to indicate their level of 
support for S/MIME. 


3. Failure Cases 


Section 23.2 of [RFC3261] requires that the recipient of a SIP 
request that includes a body part of an unsupported media type and a 
Content-Disposition header field "handling" parameter of "required" 
return a 415 (Unsupported Media Type) response. Given that SIP 
MESSAGE exists for no reason other than to deliver content in the 
body, it is reasonable to treat the top-level body part as always 
required. However, [RFC3428] makes no such assertion. This document 
updates Section 11.3 of [RFC3428] to add the statement that a UAC 
that receives a SIP MESSAGE request with an unsupported media type 
MUST return a 415 response. 


Section 23.2 of [RFC3261] says that if a recipient receives an S/MIME 
body encrypted to the wrong certificate, it MUST return a SIP 493 
(Undecipherable) response and SHOULD send a valid certificate in that 
response. This is not always possible in practice for SIP MESSAGE 


requests. The UAS may choose not to decrypt a message until the user 
is ready to read it. Messages may be delivered to a message store or 
Sent via a store-and-forward service. This document updates RFC 3261 


to say that the UAS SHOULD return a SIP 493 response if it 
immediately attempts to decrypt the message and determines that the 
message was encrypted to the wrong certificate. However, it MAY 
return a 200-class response if decryption is deferred. 


Using S/MIME with MSRP 


MSRP has features that interact with the use of S/MIME. In 
particular, the ability to send messages in chunks, the ability to 
send messages of unknown size, and the use of SDP to indicate 
media-type support create considerations for the use of S/MIME. 


1. Chunking 


MSRP allows a message to be broken into "chunks" for transmission. 
In this context, the term "message" refers to an entire message that 
one user might send to another. A chunk is a fragment of that 
message sent in a single MSRP SEND request. All of the chunks that 
make up a particular message share the same Message-ID value. 
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The sending UA may break a message into chunks, which the receiving 
UA will reassemble to form the complete message. Intermediaries such 
as MSRP relays [RFC4976] might break chunks into smaller chunks or 
might reassemble chunks into larger ones; therefore, the message 
received by the recipient may be broken into a different number of 
chunks than were sent by the recipient. Intermediaries might also 
cause chunks to be received in a different order than sent. 


The sender MUST apply any S/MIME operations to the whole message 
prior to breaking it into chunks. Likewise, the receiver needs to 
reassemble the message from its chunks prior to decrypting, 
validating a signature, etc. 


MSRP chunks are framed using an end-line. The end-line comprises 
seven hyphens, a 64-bit random value taken from the start line, anda 
continuation flag. MSRP requires the sending UA to scan data to be 
sent in a specific chunk to ensure that the end-line does not 
accidentally occur as part of the data. This scanning occurs ona 
chunk rather than a whole message; consequently, it must occur after 
the sender applies any S/MIME operations. 


8.2. Streamed Data 


MSRP allows a mode of operation where a UA sends some chunks of a 
message prior to knowing the full length of the message. For 


xample, a sender might send streamed data over MSRP as a single 
message, even though it doesn’t know the full length of that data in 
advance. This mode is incompatible with S/MIME, since a sending UA 


must apply S/MIME operations to the entire message in advance of 
breaking it into chunks. 


Therefore, when sending a message in an S/MIME format, the sender 
MUST include the Byte-Range header field for every chunk, including 
the first chunk. The Byte-Range header field MUST include the total 
length of the message. 


A higher layer could choose to break such streamed data into a series 
of messages prior to applying S/MIME operations, so that each 
fragment appears as a distinct (separate) S/MIME message in MSRP. 
Such mechanisms are beyond the scope of this document. 
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8.3. Indicating Support for S/MIME 


A UA that supports this specification MUST explicitly include the 
appropriate media type or types in the "accept-types" attribute in 
any SDP offer or answer that proposes MSRP. It MAY indicate that it 
requires S/MIME wrappers for all messages by putting appropriate 
S/MIME media types in the "accept-types" attribute and putting all 
other supported media types in the "accept-wrapped-types" attribute. 


For backwards compatibility, a sender MAY treat a peer that includes 
an asterisk ("*") in the "accept-types" attribute as potentially 
supporting S/MIME. If the peer returns an MSRP 415 (MIME type not 
understood) response to an attempt to send an S/MIME message, the 
sender should treat the peer as not supporting S/MIME for the 
duration of the session, as indicated in Section 7.3.1 of [RFC4975]. 


While these SDP attributes allow an endpoint to express support for 
certain media types only when wrapped in a specified envelope type, 
it does not allow the expression of more complex structures. For 
example, an endpoint can say that it supports text/plain and 
text/html, but only when inside an application/pkcs7 or message/cpim 
container, but it cannot express a requirement for the leaf types to 
always be contained in an application/pkcs7 container nested inside a 
message/cpim container. This has implications for the use of S/MIME 
with the message/cpim format. (See Section 9.1.) 


MSRP allows multiple reporting modes that provide different levels of 
feedback. If the sender includes a Failure-Report header field with 
a value of "no", it will not receive failure reports. This mode 
should not be used carelessly, since such a sender would never see a 
415 response as described above and would have no way to learn that 
the recipient could not process an S/MIME body. 


8.4. MSRP URIS 


MSRP URIs are ephemeral. Endpoints MUST NOT use MSRP URIs to 
identify certificates or insert MSRP URIs into certificate Subject 
Alternative Name fields. When MSRP sessions are negotiated using SIP 
[RFC3261], the SIP AoRs of the peers are used instead. 


Note that MSRP allows messages to be sent between peers in either 
direction. A given MSRP message might be sent from the SIP offerer 
to the SIP answerer. Thus, the sender and recipient roles may 
reverse between one message and another in a given session. 
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5. Failure Cases 


Successful delivery of an S/MIME message does not indicate that the 
recipient successfully decrypted the contents or validated a 
signature. Decryption and/or validation may not occur immediately on 
receipt, since the recipient may not immediately view the message, 
and the UA may choose not to attempt decryption or validation until 
the user requests it. 


Likewise, successful delivery of S/MIME enveloped data does not, on 
its own, indicate that the recipient supports th nclosed media 
type. If the peer only implicitly indicated support for the enclosed 
media type through the use of a wildcard in the "accept-types" or 
"accept-wrapped types" SDP attributes, it may not decrypt the message 
in time to send a 415 response. 


S/MIME Interaction with Other SIP Messaging Features 
1. Common Profile for Instant Messaging 


The Common Profile for Instant Messaging (CPIM) [RFC3860] defines an 
abstract messaging service, with the goal of creating gateways 
between different messaging protocols that could relay instant 
messages without change. The SIP MESSAGE method and MSRP were 
initially designed to map to the CPIM abstractions. However, at the 
time of this writing, CPIM-compliant gateways have not been deployed. 
To the authors' knowledge, no other IM protocols have been explicitly 
mapped to CPIM. 


CPIM also defines the abstract messaging URI scheme "im:". As of the 
time of this writing, the "im:" scheme is not in common use. 


The CPIM message format [RFC3862] allows UAs to attach 
transport-neutral metadata to arbitrary MIME content. The format was 
designed as a canonicalization format to allow signed data to cross 
protocol-converting gateways without loss of metadata needed to 
verify the signature. While it has not typically been used for that 
purpose, it has been used for other metadata applications -- for 
example, IMDNs [RFC5438] and MSRP multi-party chat [RFC7701]. 


In the general case, a sender applies end-to-end signature and 
encryption operations to the entire MIME body. However, some 
messaging systems expect to inspect and in some cases add or modify 
metadata in CPIM header fields. For example, CPM-based and RCS-based 
Services include application servers that may need to insert 
timestamps into chat messages and may use additional metadata to 
characterize the content and purpose of a message to determin 
application behavior. The former will cause validation failure for 
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signatures that cover CPIM metadata, while the latter is not possible 
if the metadata is encrypted. Clients intended for use in such 
networks MAY choose to apply end-to-end signatures and encryption 
operations to only the CPIM payload, leaving the CPIM metadata 
unprotected from inspection and modification. UAs that support 
S/MIME and CPIM SHOULD be able to validate signatures and decrypt 
enveloped data both (1) when those operations are applied to the 
entire CPIM body and (2) when they are applied to just the CPIM 
payload. This means that the receiver needs to be flexible in its 
MIME document parsing and that it cannot make assumptions that 
S/MIME-protected body parts will always be in the same position or 
level in the message payload. 


If such clients need to encrypt or sign CPIM metadata end to end, 
they can nest a protected CPIM message format payload inside an 
unprotected CPIM message envelop 


The use of CPIM metadata fields to identify certificates or to 
authenticate SIP or MSRP header fields is out of scope for this 
document. 


9.2. Instant Message Disposition Notifications 


The IMDN mechanism [RFC5438] allows both endpoints and intermediary 
application servers to request and to generate delivery 
notifications. The use of S/MIME does not impact strictly end-to-end 
use of IMDNs. The IMDN mechanism recommends that devices that are 
capable of doing so sign delivery notifications. It further requires 
that delivery notifications that result from encrypted messages also 
be encrypted. 


However, the IMDN mechanism allows intermediary application servers 
to insert notification requests into messages, to add routing 
information to messages, and to act on notification requests. It 
also allows list servers to aggregate delivery notifications. 


Such intermediaries will be unable to read end-to-end encrypted 
messages in order to interpret delivery notice requests. 
Intermediaries that insert information into end-to-end signed 
messages will cause the signature validation to fail. (See 
Section 9.1.) 
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10. 


10. 


Examples 


The following sections show examples of S/MIME messages in SIP and 
MSRP. The examples include the tags "[start-hex]" and "[end-hex]" to 
denote binary content shown in hexadecimal. The tags are not part of 
the actual message and do not count towards the Content-Length header 
field values. 


In all of these examples, the cleartext message is the string 
"Watson, come here - I want to see you." followed by a newline 
character. 


The cast of characters includes Alice, with a SIP AoR of 
"alice@example.com", and Bob, with a SIP AoR of "bob@example.org". 


Appendix A shows the detailed content of each S/MIME body. 
1. Signed Message in SIP including the Sender’s Certificate 


Figure 1 shows a message signed by Alice. This body uses the 
"application/pkcs7-mime" media type with an smime-type parameter 
value of "signed-data". 


The S/MIME body includes Alice's signing certificate. Even though 
the original message content is fairly short and only minimal SIP 
header fields are included, the total message size approaches the 
maximum allowed for the SIP MESSAGE method unless the UAC has advance 
knowledge that all SIP hops will use congestion-controlled transport 
protocols. A message that included all the SIP header fields that 
are commonly in use in some SIP deployments would likely exceed th 
limit. 
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MESSAGE sip:bob@example.org SIP/2.0 

Via: SIP/2.0/TCP alice-pc.example.com;branch-z9hGA4bK776sgdkfie 

Max-Forwards: 70 

From: sip:alice@example.com; tag=49597 

To: sip:bob@example.org 

Call-ID: asd88asd66b@1.2.3.4 

CSeq: 1 MESSAGE 

Content-Transfer-Encoding: binary 

Content-Type: application/pkcs7-mime; smime-type-signed-data; 
name-"smime.p7m" 

Content-Disposition: attachment; filename-"smime.p7m" 

Content-Length: 762 


[start-hex] 
308202f606092a864886f70d010702a08202e7308202e3020101310d300b0609 
608648016503040201305306092a864886£708010701a0460444436£6e74656e 
742d4d547970653a20746578742£706c61696e0d0a0d0a576174736£6e2c20636£ 
64d652068657265202420492077616e7420746£2073656520796£752e0d0aa082 
01650308201673082010da003020102020900508793ec0e4c21530300a06082a86 
48ce3d4040302302631143012060355040a0c0506578616d706c652e636f£6d310e 
300c06035504030c05416c696365301e170d3137313231393233313230355a17 
0d3138313231393233313230355a302631143012060355040a0c0b6578616d70 
6c652e636f6d310e300C06035504030c05416c6963653059301306072a8648ce 
3d4020106082a8648ce34d4030107034200044875054729£2c22f£eebd9ddba0efa40 
642297a6093887a4dae79905023£87fa7ed99db8cf5a314f£2ee64106ef1ed61db 
f£c0a4b91c953cbhd022a751b914807bb7 94a324302230200603551d1104193017 
86157369703a616c696365406578616d706c652e636f6d300a06082a8 648ce3d 
04030203480030450220787 9be1lc27£846276fdf£15e333e53c6f17a757388a02 
cb7b8ae481c164lae7a9022100F£99Cd9CI4076c82b02fea3b1350179a4b7752 
el6fa30a3f9ab29650b0eE2818931820109308201050201013033302631143012 
060355040a0c056578616d706c652e636£6d310e300c06035504030c05416c69 
6365020900508793ec0e4c21530300500609608648016503040201a06930180609 
2a864886£704d010903310506092a864886£704010701301c06092a864886£70d 
010905310£170d3139303132363036313335345a302£06092a864886£70d0109 
0431220420ef 778 £c940d5e6dc2576£47a599b3126195a9fla227adaf35fa22c 
050d8d195a300a06082a8 648ce3d04030204473045022005fdc2b55b0f444a46 
be468dfc7ef3b7de30019e£0952a2236e8521890535bb4e02210090e43a9d9846 
cf2af8159c5c0ef48848fa2£39£998b1bb99b52a6fc6c776£2c8 

[end-hex] 


Figure 1: Signed Message in SIP 
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10.2. Signed Message in SIP with No Certificate 


Figure 2 shows the same message from Alice without the embedded 
certificate. The shorter total message length may be more 
manageable. 


MESSAGE sip:bob@example.org SIP/2.0 

Via: SIP/2.0/TCP alice-pc.example.com;branch=z9hG4bK776sgdkfie 

Max-Forwards: 70 

From: sip:alice@example.com; tag=49597 

To: sip:bob@example.org 

Call-ID: asd88asd66b@1.2.3.4 

CSeq: 1 MESSAGE 

Content-Transfer-Encoding: binary 

Content-Type: application/pkcs7-mime; smime-type-signed-data; 
name-"smime.p7m" 

Content-Disposition: attachment; filename-"smime.p7m" 

Content-Length: 395 


[start-hex] 
3082018706092a864886f70d010702a082017830820174020101310d300b0609 
608648016503040201305306092a864886f70d010701a0460444436f6e74656e 
742d4d547970653a20746578742£706c61696e0d0a0d0a576174736£6e2c20636£ 
6d652068657265202d20492077616e7420746f2073656520796fF752e0d0a3182 
0109308201050201013033302631143012060355040a0c0b6578616d706c652e 
636£6d310e300c06035504030c05416c696365020900b8793ec0e4c21530300b 
0609608648016503040201a069301806092a864886Ff70d010903310b06092a86 
4886£70d010701301c06092a864886£70d010905310£170d3139303132363036 
313335345a302f£06092a864886£70d01090431220420e£778£c940d5e6dc2576 
£47a599b3126195a9f1la227adaf35fa22c050d8d195a300a06082a8648ce3d04 
03020447304502203607275592d30c8c5a931041a01804d60c638ac9Ia8080918 
87172a0887c8d4aa022100cd9e14bd21817336e9052fe590af2e2bcdel6dd3e9 
48d0f5£78a969e26382682 
[end-hex] 


Figure 2: Signed Message in SIP with No Certificate Included 
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10.3. MSRP Signed and Encrypted Message in a Single Chunk 


Figure 3 shows a signed and encrypted message from Bob to Alice sent 
via MSRP. 


MSRP dsdfoe38sd SEND 

To-Path: msrp://alicepc.example.com:7777/iau39soe2843z;tcp 

From-Path: msrp://bobpc.example.org:8888/9di4eae923wzd;tcp 

Message-ID: 456s039s 

Byte-Range: 1-1940/1940 

Content-Disposition: attachment; filename-"smime.p7m" 

Content-Type: application/pkcs7-mime; smime-type-auth-enveloped-data; 
name-"smime.p7m" 


[start-hex] 

30820790060b2a864886f70d0109100117a082077£3082077b0201003182024F 
3082024500201003033302631143012060355040a0c0056578616d706c652e636£f 
6d310e300c06035504030c05416c69636502090083£505bb70b5bd5c40e300d0609 
2a864886f£704d010101050004820200759a61b4ddf1f1af24668005635e476110 
fa2723c1b9e45484b6d43368387de967dc5e0cafb35571a56a1975cb550e7be31 
c131da80f£b731024845babb8d64cac26040424d9330561c843999415dd644b3c 
ad95072£71451393c99f282c4883bd0ccc5dd54b931464e00a6e55e592c51a68 
de1062516ec7d3ca8e7 64bb8ac78 9a88377765ef 8dc36c0abed3ecae5285cac6 
a29d5059445719al1bdcf906e0ff37e2c2ef0f4ec6225100cc062e1c748963bbc 
88b8e3dfcf714073729dd5c7583e758acf3d186£2£fa417be22c37c9a76c65b427 
29aad27f£73ae44ac98474d1eeb48948c12a403d0b3ce08a218d6af456924897c 
c5c9664f6dfeb3f18141158dfc3b84090aa60380aa865137e1699c5c81974167 
9d7a3c90ba79e6d7d5c8d489bb54a667423e43b0b7d6£78c0b4ab6750c343662a6 
35fe595f1149c53950cac2e0ba318c227e6f£76a8d940400£d3d3ea1c8ecea003 
dcce2f1fb00f5cea335de1303fcbf93d8elcbfd682f19beb624bacdl1d75b8f580 
f114a13b890894fb4044a5daa764b7£8c5££929494525035aeb9639b8ad63c051 
5c95ccc6£823c2201067ea2262413£e£3977d48£7506143£842ae8e1a48cad3ae0 
labaa3cf9ee7e36620e05cca0611bfac00eefl1a498f2d259b9f0f7da83ef6f1b 
061£387c2dc48c8b5dbaca862308£32£47925165c9e5ebb467799884918dd697 
b447£4c4079895088950c2e9580a£783082050£06092a864886£704d010701301e 
06096086480165030401063011040c4d8757222eac5294117£0c120201108082 
04e0fe2f£Db3de0bf06998c39bf4a952fabf8b0fee3d7e2e85181aecf1a89e1a2e 
decd9404885612d£c6984334d8602b7749b2504e45f57c3b066626b0fc746236 
1eec267c560139be5cd286a2af£9696c£51852278e52c3818cab0a68c598de4fc 
el4a333884e4de5ddf57edd78867027a31e4a7c0c0299144c5de6bae39699e70 
0e057eb0 £0dad73b8b369f42eb321b41538781d982a11a0b3943acl0c97b54ee 
b735b38ec131afc5610e373487274d69cafa9541902886c64£6962d42eb33£904 
1la4ae11b88dc6958d53df50b8bb52aa35e2299885d0aae41 6b86f0a88d0eb7a9 
81dbb283e8b94e9d50bf6265c2348a18a169aacb5a37a529bda2£f9cb10efddcf 
14231095d4879646370d33f£b13c68b4cff9a1906960c1ea2301d3255b7a15c5829 
f3ea038£24df60231803774d37131£75db18£41£9d485b653dfa46b£2617126326 
ccf1cb833457752352c8417a094484d7b64bcf51b26a9beb3a0ed4b9caf1bd23 
c690c654f7eb9ce9852e2f£6d068eef8ba33bc6c4dddca7aef4d35747377d 7 c4dc 
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1e93770d8f4f22dea614d73083c32c4038c1eb3dd3383a89a8795e241c2ed7cb6 
80758c041069489860£c9£490e8523607254803249698£99953acf1ec658b7aa 
85e554c449701a6d4b039ed103dc458df4b29cb04b8cedd540c84348da79c186 
56d5188£9£f3a9e4595840c706645090296c6057ac984e918d48a09dbddf5b281fc 
862510db59d9fa9dc93f10f9c6d7bef72931d184cad7ac13c1a5295fc89fe3bb 
7e58e02085a828c5a138786e607ade4f£5e8d41159092095a878a79305a5316c2 
2229e4250886d06481c8473£9d51269e2af£6341bce20£768e860d7784ed46150e 
04£f50cd209c5b127511369fe06bc4aa9a72d8f1fe4fcf0866d664b365ffa86e 
8c1b43e7a9212aecc16ca350a28efae25fac054dd934bfe7e5fa4f753aa41596 
8c7ebec439e0ac0270504874a0684d22484c09d9e8abe17£1372b4b2f£65£1148e8 
933eda92e5d1774564963b391c3bbd9f1c27££e36£832e05155f£c39ee6652£a7 
D4188975ec5c675032c9£213c8ac6b8e132a5a7c3bf£74£016405cd8c201d10521 
93e186d44358de3884d8732115ba2£1792£3cfeb9bbde7211d26f£56ab06e11ccc9c 
cde2588cd8373773ea£c37£085b7a7a2bcaec752e617d6e01c02586e9d9a40£3 
20462c5d66£8351716dcd6014bdf30a60£75£:c0631c920845ed8c0bad35ddf19 
84£2241cd3b529dc1028845£8089543df4f1441ede36b1bf31af5afc8c2b708d 
50b645d4e7db88648c3eefel4765158fb0e8d3bb53ddcbe26d7124c6e1d992f£8 
3230aa953376ee8c68109568e8571£f0c9bbda48f4df306fe747£371175148£31 
832767cd766cf07b450cbf62cad2a7bd71f£1f£88233f116a1a7f£3caf12f£34bcf4 
0d21e79ff:c9827221050680080ff03ad782d6d6d07871676£798943e54f£13f£d75c 
89c0b4263bf£10£56243f£9e72e£3503899a539d9a3ac5be2b69400a3cf8d196c5c 
ed6975b2ed8035b987a5ee85c5095b48da7a5b03b47e2b9fe4cd4bc3098e864e0c 
e7d467da99cd7f3a9e947b5eea77£f7a6bel6c8c7e9e0decc1ff132559c234321 
769c2950386e85d2942121086cdfal 96581 95be6d7 £8 6bca9881b695082964F1 
2e7cf£801025d6792c6882409414d703321ec83abd698d68956118713a0f £1272 
acbc9a6d148900c74c16921df9b38F29ec46d4f10060fffeb5e36bbbacaf2dlba 
d7dd057ed3e30ebcd69083f£9d3a2a26ef90b751d6aladfa0590db19da107cf3e 
a8db0410f6ffc6elaef19cd23d985a921976352d 

[end-hex] 

rri EE dsdfoe38sd$ 


Figure 3: Signed and Encrypted Message in MSRP 
10.4. MSRP Signed and Encrypted Message Sent in Multiple Chunks 
Figure 4 shows the same message as in Figure 3 except that the 


message is broken into two chunks. The S/MIME operations were 
performed prior to breaking the message into chunks. 


MSRP d93kswow SEND 

To-Path: msrp://alicepc.example.com:7777/iau39soe2843z;tcp 

From-Path: msrp://bobpc.example.org:8888/9di4eae923wzd;tcp 

Message-ID: 12339sdqwer 

Byte-Range: 1-960/1940 

Content-Disposition: attachment; filename-"smime.p7m" 

Content-Type: application/pkcs7-mime; smime-type-enveloped-data; 
name-"smime.p7m" 
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[start-hex] 
30820790060b2a864886f70d0109100117a082077£3082077b0201003182024F 
3082024b0201003033302631143012060355040a0c0b6578616d706c652e636f 
6d310e300c06035504030c05416c69636502090083f50bb70bd5c40e300d0609 
2a864886£70d010101050004820200759a61b4ddf1lflaf24668005635e476110 
£a2723c1b9e4548 4b6d33e8387de9I67dc5e0cafb35571a56a1975cb550e7be31 
c131da80f£b731024845babb8d64cac26040424d9330561c843999415dd644b3c 
ad95072£71451393c99f282c4883bd0ccc5dd54b931464e00a6e55e592c51a68 
de1062516ec7d3ca8e764bb8ac789a88377765ef8dc36c0a6ed3ecae5285cac6 
a29d5059445719al1bdcf906e0ff37e2c2ef0f4ec6225100cc062e1c748963bbc 
88b8e3dfcf714073729dd5c7583e758acf3d186£2£fa417be22c37c9a76c65b427 
29aad27f73ae44ac98474d1eeb48948c12a403d0b3ce08a218d6af456924897c 
c5c9664f6dfeb3f18141158dfc3b84090aa60380aa865137e1699c5c81974167 
9d7a3c90ba79e6d7d5c8d489bb54a667423e43b0b7d6£78c0b4ab6750c343662a6 
35fe595f1149c53950cac2e0ba318c227e6f£76a8d940400£d3d3ea1c8ecea003 
dcce2f1fb00f5cea335de1303fcbf93d8elcbfd682f19beb624bacdl1d7b8f580 
f114a135b890894fb4044a5daa764b7£8c5f££929494525035aeb9639b8ad63c051 
5c95ccc6£823c2201067ea2262413£e£3977d48£7506143£842ae8e1a48cad3ae0 
labaa3cf9ee7e36620e05cca0611bfac00eefla498f2d259b9f0f7da83ef6f1b 
061£387c2dc48c8b5dbaca862308£32£47925165c9e5ebb467799884918dd697 
b447£4c4079895088950c2e9580a£783082050£06092a864886£704d010701301e 
06096086480165030401063011040c4d8757222eac5294117£0c120201108082 
04e0fe2f£b3de0bf06998c39bf4a952fabf8b0fee3d7e2e85181aecf1a89e1a2e 
decd9404885612d£c6984334d8602b7749b2504e45£57c3b066626b0fc746236 
1eec267c560139be5cd286a2a£9696c£51852278e52c3818cab0a68c598de4fc 
el4a333884e4de5ddf57edd78867027a31e4a7c0c0299144c5de6bae39699e70 
0e057eb0 £0dad73b8b369Ff42eb321b41538781d982a11a0b3943acl0c97b54ee 
b73b38ec131afc5610eE373487274d69cafa9541902886cb64Ff6962d42eb33f904 
1la4ae11b88dc6958d53df50b8bb52aa35e2299885d0aae41 6b86f0a88d0eb7a9 
81dbb283e8b94e9d50bf6265c2348a18a169aacb5a37a529bda2£f9cb10efddcf 
14231095d48796463705d33f£b13c68b4cff9a1906960c1ea2301d325b5b7a15c5829 
[end-hex] 

Rr d93kswow+ 


MSRP op2nc9a SEND 

To-Path: msrp://alicepc.example.com: 8888/9di4eae923wzd; tcp 

From-Path: msrp://bobpc.example.org:7654/iau39soe2843z;tcp 

Message-ID: 12339sdqwer 

Byte-Range: 961-1940/1940 

Content-Disposition: attachment; filename-"smime.p7m" 

Content-Type: application/pkcs7-mime; smime-type-enveloped-data; 
name-"smime.p7m" 


Campbell & Housley Standards Track [Page 22] 


RFC 8591 S/MIME for SIP Messaging April 2019 


[start-hex] 
f3ea038£24df60231803774d37131£75db18£41£9d485b653dfa46b£2617126326 
ccf1cb833457752352c8417a094484d7b64bcf51b26a9beb3a0ed4b9caf1bd23 
c690c654f7eb9ce9852e2£6d068eef8ba33bc6c4dddca7aef4d3574737d7c4dc 
1e93770d8f4f22dea614d73083c32c4038c1eb3dd3383a89a8795e241c2ed7cb6 
80758c041069489860£c9£490e8523607254803249698£99953acf1ec658b7aa 
85e554c449701a6d4b039ed103dc458df4b29cb04b8cedd540c84348da79c186 
56d5188£9f£3a9e4595840c706645090296c6057ac984e918d48a09dbddfb281fc 
862510db59d9fa9dc93f10f9c6d7bef72931d184cad7ac13c1a5295fc89fe3bb 
7e5b8e02085a828c5a138786e607ade4f£5e8d41159092095a878a79305a5316c2 
2229e420886d06481c8473£94d51269e2af£6341bce20£768e860d7784ed46150e 
04£f50cd209c5b127511369fe06bc4aa9a72d8f1fe4fcf0866d664b365ffa86e 
8c1b43e7a9212aecc16ca350a28efae25fac054dd934bfe7e5fa4f753aa41596 
8c7ebec439e0ac027054874a068822484c09d9e8abe17£1372b4b2£65f£1148e8 
933eda92e5d1774564963b391c3bbd9f1c27££e36£832e05155f£c39ee6652£fa7 
D4188975ec5c675032c9£213c8ac6b8e132a5a7c3bf£74£016405cd8c201d10521 
93e186d44358de3884d732115ba2£1792£3cfeb9bbde7211d26f£56ab06e11ccc9c 
cde2588cd8373773eafc37£d85b7a7a2bcaec752e617d6e01c025086e9d9a40£3 
20462c5d66£8351716dcd6014bdf30a60£75£:c0631c920845ed8c0bad35ddf19 
84£2241cd3b529dc1028845£8089543df4f1441ede36b1bf31af5afc8c2b708d 
50b645d4e7db88648c3eefel4765158fb0e8d3bb53ddcbe26d7124c6e1d992f£8 
3230aa953376ee8c68109568e8571£f0c9bbda48f4df306fe747£371175148£31 
832767cd766cf07b450cbf62cad2a7bd71f1f£88233f116a1a7f3caf12f£34bcf4 
0d21e79£ffc9827221050680080f£f03ad782d6d6d07871676£798943e54f£13f£d75c 
89c0b4263bf£10£56243f£9e72e£3503899a539d9a3ac5be25b69400a3cf8d196c5c 
ed6975b2ed8035b987a5ee85c5095b48da7a5b03b47e2b9fe4cd4bc3098e864e0c 
e7d467da99cd7f3a9e947b5eea77£7a6bel6c8c7e9e0decc1ff132559c234321 
769c2950386e85d2942121086cdfal 96581 95be6d7 £8 6bca9881b695082964F1 
2e7cf£801025d6792c6882409414d703321ec83abd698468956118713a0££1272 
acbc9a6d148900c74c16921d£9038£29ec46d4f10060fffe5e36bbbacaf2dlba 
d7dd057ed3e30ebcd69083f£9d3a2a26ef90b751d6al1adfa0590db19da107cf3e 
a8db0410f6ffc6elaef19cd23d985a921976352d 

[end-hex] 

c E EE op2nc9a$ 


Figure 4: Signed, Encrypted, and Chunked MSRP Message 
11. IANA Considerations 
This document has no IANA actions. 
12. Security Considerations 
The security considerations for S/MIME [RFC8550] [RFC8551] and 
elliptic curves in CMS [RFC5753] apply. The S/MIME-related security 


considerations for SIP [RFC3261], SIP MESSAGE [RFC3428], and MSRP 
[RFC4975] apply. 
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The security considerations for algorithms recommended in this 
document also apply; see [RFC3565], [RFC5480], [RFC5753], [RFC5754], 
RFC7748], [RFC8032], [RFC8418], and [RFC8419]. 


This document assumes that end-entity certificate validation is 
provided by a chain of trust to a certification authority (CA), using 
a public key infrastructure. The security considerations from 
RFC5280] apply. However, other validations methods may be possible 
-- for example, sending a signed fingerprint for the end entity in 
SDP. The relationship between this work and the techniques discussed 
in [RFC8224] and [RTP-Sec] are out of scope for this document. 


When matching an end-entity certificate to the sender or recipient 
identity, the respective SIP AoRs are used. Typically, these will 
match the SIP From and To header fields. Some UAs may extract the 
sender identity from SIP AoRs in other header fields -- for example, 
P-Asserted-Identity [RFC3325]. In general, the UAS should compare 
the certificate to the identity that it relies upon -- for example, 
for display to the end user or comparison against message-filtering 
rules. 


The secure notification use case discussed in Section 1 has 
significant vulnerabilities when used in an insecure environment. 
For example, "phishing" messages could be used to trick users into 
revealing credentials.  Eavesdroppers could learn confirmation codes 
from unprotected two-factor authentication messages.  Unsolicited 
messages sent by impersonators could tarnish the reputation of an 
organization. While hop-by-hop protection can mitigate some of those 
risks, it still leaves messages vulnerable to malicious or 
compromised intermediaries.  End-to-end protection prevents 
modification by intermediaries. However, neither provides much 
protection unless the recipient knows to expect messages from a 
particular sender to be signed and refuses to accept unsigned 
messages that appear to be from that source. 


Mobile messaging is typically an online application; online 
certificate revocation checks should usually be feasible. 


S/MIME does not normally protect the SIP or MSRP headers. While it 
normally does protect the CPIM header, certain CPIM header fields may 
not be protected if the sender excludes them from the encrypted or 
Signed part of the message. (See Section 9.1.) Certain messaging 
Services -- for example, those based on RCS -- may include 
intermediaries that attach metadata to user-generated messages in the 
form of SIP, MSRP, or CPIM header fields. This metadata could 
possibly reveal information to third parties that the sender might 
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prefer not to send as cleartext. Implementors and operators should 
consider whether inserted metadata may create privacy leaks. Such an 
analysis is beyond the scope of this document. 


MSRP messages broken into chunks must be reassembled by the recipient 
prior to decrypting or validation of signatures. (See Section 8.1.) 
Section 14.5 of [RFC4975] describes a potential denial-of-service 
attack where the attacker puts large values in the Byte-Range header 
field.  Implementations should sanity-check these values before 
allocating memory space for reassembly. 


Modification of the ciphertext in EnvelopedData can go undetected if 
authentication is not also used, which is the case when sending 
EnvelopedData without wrapping it in SignedData or enclosing 
SignedData within it. This is one of the reasons for moving from 
EnvelopedData to AuthEnvelopedData, as the authenticated encryption 
algorithms provide the authentication without needing the SignedData 
layer. 


An attack on S/MIME implementations of HTML and multipart/mixed 
messages is highlighted in [Efail]. To avoid this attack, clients 
MUST ensure that a text/html content type is a complete HTML 
document. Clients SHOULD treat each of the different pieces of the 
multipart/mixed construct as coming from different origins. Clients 
MUST treat each encrypted or signed piece of a MIME message as being 
from different origins both from unprotected content and from each 
other. 
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The following section shows the detailed content of the S/MIME bodies 


used in Section 10. 


A.1. Signed Message 


Figure 5 shows the details of the message signed by Alice used in the 


example in Section 10.1. 


CMS ContentInfo: 


contentType: pkcs7-signedData 


d.signedData: 
version: 1 
digestAlgorithms: 


algorithm: sha256 (2.16.840.1.101.3.4.2.1) 


parameter: «ABSENT» 
encapContentInfo: 


eContentType: pkcs7-data 


eContent: 
0000 - 43 6f 6e 74 65 Ge 
000f£ - 65 78 74 2f 70 6c 
001e - 74 73 6f 6e 2c 20 
002d - 20 2d 20 49 20 77 
003c - 65 20 79 6f 75 Ze 
certificates: 
d.certificate: 
cert info: 
version: 2 


74 
61 
63 
61 
Od 


(1.2. 


2d-54 
69-6e 
6f-6d 
6e-74 
0a- 


840.113549.1.7. 


79 70 
Od Oa 
65 20 
20 74 


65 
0d 
68 
6f 


serialNumber: 13292724773353297200 


signature: 


algorithm: ecdsa-with-SHA256 
parameter: «ABSENT» 


issuer: O=example.com, 


validity: 


CN- 


Alice 


3a 
0a 
65 
20 


notBefore: Dec 19 23:12:05 2017 GMT 
notAfter: Dec 19 23:12:05 2018 GMT 


subject: O=example.com, 


key: 
algor: 


algorithm: id-ecPublicKey 
parameter: OBJECT:prime256v1 


CN-Alice 


public key: (0 unused bits) 


0000 - 04 d8 7b 54 72 9f 
000e - fa 40 64 22 97 a6 
001c - 23 f8 7f a7 ed 99 
002a - 10 6e f1 ed 61 db 
0038 - 22 a7 51 b9 14 80 
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2c 
09 
db 
fc 
7b 


22-fe 
38-87 
8c-f5 
0a-4b 
b7-94 


eb d9 
a4 da 
a3 14 
91 c9 


dd 
e7 
f2 
53 
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ba 
99 
ee 
cb 


20 
57 
72 
73 


(1.2.840.113549.1.7.2) 


Content-Type: t 
ext/plain....Wa 
tson, come here 
- I want to se 
e you... 


(1.2.840.10045.4.3.2) 


(1.2.840.10045.2.1) 
(1.2. 


840.10045.3.1.7) 


0e 
0b 
64 
dO 
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issuerUID: <ABSENT> 
subjectUID: <ABSENT> 
extensions: 
object: X509v3 Subject Alternative Name (2.5.29.17) 
critical: BOOL ABSENT 
value: 
0000- 30 17 86 15 73 69 70 3a-61 6c 69 63 65 0...sip:alice 
000d - 40 65 78 61 6d 70 6c 65-2e 63 6f 6d @example.com 
sig_alg: 
algorithm: ecdsa-with-SHA256 (1.2.840.10045.4.3.2) 
parameter: «ABSENT» 
signature: (0 unused bits) 
0000 - 30 45 02 20 78 79 be 1c-27 £8 46 27 6f df 15 ORG oxy! UECOL 
000f - e3 33 e5 3c 6f 17 a7 57-38 8a 02 cb 7b 8a ei 3.«9..W8...1.; 
001e - 81 cl 64 la e7 a9 02 21-00 ff 99 cd 9c 94 07 dica el su ves 
002d - 6c 82 bü 2f ea 3b 13 50-17 9a 4b 77 52 el 6f Lxx. KwR.o 
003c - a3 0a 3f 9a b2 96 50 b0-e2 81 89 eeu Eis 
crls: 
«ABSENT» 
signerInfos: 
version: 
d.issuerAndSerialNumber: 
issuer: O=example.com, CN-Alice 
serialNumber: 13292724773353297200 
digestAlgorithm: 
algorithm: sha256 (2.16.840.1.101.3.4.2.1) 
parameter: «ABSENT» 
signedAttrs: 
object: contentType (1.2.840.113549.1.9.3) 
set: 
OBJECT:pkcs7-data (1.2.840.113549.1.7.1) 
object: signingTime (1.2.840.113549.1.9.5) 
set: 
UTCTIME:Jan 24 23:52:56 2019 GMT 
object: messageDigest (1.2.840.113549.1.9.4) 
set: 
OCTET STRING: 
0000 - ef 77 8f c9 40 db e6 dc-25 76 f4 7a 59 w..8Q...S9v.zY 
000d - 9b 31 26 19 5a 9f la 22-7a da f3 5f a2 TE AS AS M. 
001a - 2c 05 Od 8d 19 5a area Le 


signatureAlgorithm: 
algorithm: 
parameter: 
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ecdsa-with-SHA256 
«ABSENT» 


(1.2.840.10045.4.3.2) 
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signature: 
0000 - 30 45 02 20 58 79 cc 62-85 eO 86 06 19 d3 bf 0 
000f - 53 d4 67 9f 03 73 d7 45-20 cf 56 10 c2 55 5b SA CR Nell 
00le - 7b ec 61 d4 72 dc 02 21-00 83 aa 53 44 28 4d {.a 
002d - 4c ef de 31 07 9c £9 71-bd 69 5d 6e c8 71 e9 Es 
003c - a4 60 ec 2e 12 65 2b 77-a4 62 4d . `... +W. DM 
unsignedAttrs: 
<ABSENT> 


Figure 5: Signed Message 


A.2. Short Signed Message 


Figure 6 shows the message signed by Alice with no embedded 
certificate, as used in th xample in Section 10.2. 


CMS ContentInfo: 
contentType: pkcs7-signedData (1.2.840.113549.1.7.2) 
d.signedData: 
version: 1 
digestAlgorithms: 
algorithm: sha256 (2.16.840.1.101.3.4.2.1) 
parameter: «ABSENT» 
encapContentInfo: 
eContentType: pkcs7-data (1.2.840.113549.1.7.1) 
eContent: 
0000 - 43 6f 6e 74 65 6e 74 2d-54 79 70 65 3a 20 74 Content-Type: t 
000f - 65 78 74 2f 70 6c 61 69-6e Od Oa Od Oa 57 61 ext/plain....Wa 
001e - 74 73 6f 6e 2c 20 63 6f-6d 65 20 68 65 72 65 tson, come here 
002d - 20 2d 20 49 20 77 61 6e-74 20 74 6f 20 73 65 - I want to se 
003c - 65 20 79 6f 75 2e Od 0a- e you... 
certificates: 
«ABSENT» 
crls: 
<ABSENT> 
signerInfos: 
version: 1 
d.issuerAndSerialNumber: 
issuer: O=example.com, CN=Alice 
serialNumber: 13292724773353297200 
digestAlgorithm: 
algorithm: sha256 (2.16.840.1.101.3.4.2.1) 
parameter: <ABSENT> 
signedAttrs: 
object: contentType (1.2.840.113549.1.9.3) 
set: 
OBJECT: pkcs7-data (1.2.840.113549.1.7.1) 
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object: signingTime (1.2.840.113549.1.9.5) 
set: 
UTCTIME:Jan 24 23:52:56 2019 GMT 


object: messageDigest (1.2.840.113549.1.9.4) 
set: 
OCTET STRING: 
0000 - ef 77 8f c9 40 db e6 dc-25 76 f4 7a 59 .w..0...S9v.zY 
000d - 9b 31 26 19 5a 9f 1a 22-7a da £3 5f a2 .1&.2.."z.. 
001a - 2c 05 Od 8d 19 5a po gases 
signatureAlgorithm: 
algorithm: ecdsa-with-SHA256 (1.2.840.10045.4.3.2) 
parameter: «ABSENT» 
signature: 
0000- 3044 02 20 1c 51 6e ed-9c 10 10 a2 87 el 11 OD. Qno aves 


000f - 6b af 76 1d f1 c4 e6 48-da ea 17 89 bc e2 8a Kov 
001e - 9d 8a f4 a4 ae £9 02 20-72 7f 5e 4b cc e2 0b  ....... ru Kl. 
002d - cf 3c af 07 c8 1c 11 64-f0 21 e7 70 eO f6 a0 SUUS di zp.v. 
003c - 96 2e 0a 7b 19 b7 42 ad-cb 34 Venu Bets a 
unsignedAttrs: 
<ABSENT> 


Figure 6: Signed Message without Embedded Certificate 
A.3. Signed and Encrypted Message 
The following sections show details for the message signed by Bob and 


encrypted to Alice, as used in the examples in Sections 10.3 
and 10.4. 


A.3.1. Signed Message prior to Encryption 


CMS_ContentInfo: 
contentType: pkcs7-signedData (1.2.840.113549.1.7.2) 
d.signedData: 
version: 1 
digestAlgorithms: 
algorithm: sha256 (2.16.840.1.101.3.4.2.1) 
parameter: <ABSENT> 
encapContentInfo: 
eContentType: pkcs7-data (1.2.840.113549.1.7.1) 
eContent: 
0000 - 43 6f 6e 74 65 6e 74 2d-54 79 70 65 3a 20 74 Content-Type: t 
000f - 65 78 74 2f 70 6c 61 69-6e Od Oa Od Oa 57 61 ext/plain....Wa 
001e - 74 73 6f 6e 2c 20 63 6f-6d 65 20 68 65 72 65 tson, come here 
002d - 20 2d 20 49 20 77 61 6e-74 20 74 6f 20 73 65 - I want to se 
003c - 65 20 79 6f 75 2e Od 0a- e you... 
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certificates: 
d.certificate: 
cert_info: 
version: 2 
serialNumber: 
signature: 
algorithm: ecdsa-with-SHA256 
parameter: <ABSENT> 
issuer: O=example.org, 
validity: 
notBefore: 
notAfter: 
subject: O=exampl 
key: 
algor: 
algorithm: 
parameter: 
public_key: 
86 4f ff fc 
7a 07 9c 71 
bd 12 74 3c 


11914627415941064473 


CN-Bob 


CN-Bob 


$Org, 


id-ecPublicKey 
OBJECT:prime256v1 
(0 unused bits) 
53 fl a8-76 ca 69 
52 ae 1b-13 7e 39 
1 7d 41 43-a2 fd 8a 
ba 9d 03 b7 30 1f 1d a6-4e 30 55 
95 cb 71 fa 48 b6 d0 a3-83 
issuerUID: «ABSENT» 
SubjectUID: «ABSENT» 
extensions: 
object: 
critical: 
value: 
30 15 86 13 
78 61 6d 70 
Sig alg: 
algorithm: 
parameter: 
signature: 
30 45 02 
25 "f 64 
d5 1b 10 
b9 bd 2e 
£7 Ac 77 


0000 - 
000e - 
001c - 
002a - 
0038 - 


04 
48 
ae 


bl 


37 


TRUE 


0000 - 
000d - 


73 69 70 3a-62 6f 62 
6c 65 2e 6f-72 67 


40 


ecdsa-with-SHA256 
«ABSENT» 
(0 unused 
00 b2 24 
fd 10 6f 
73 39 6c 
cf 27 8f 
b1 5a 4f 


(1 


bits) 

8c-92 
ba-0b 
02-20 
0d-52 
47-9d 


21 
cc 
2f 
04 
10 


22 
19 
bl 
b6 


0000 - 
000f - 
001e - 
002d - 
003c - 
Grls: 
«ABSENT» 
signerInfos: 
version: 1 
d.issuerAndSerialNumber: 
issuer: O=example.org, CN=Bob 
serialNumber: 11914627415941064473 


40 
96 
15 
2e 
e4 


28 
cl 
8e 
6b 
Od 
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Dec 20 23:07:49 2018 GMT 


7e 


3b af 


Of 


94 bb 


X509v3 Subject Alternative Name 


65 


.2.840. 


38 
07 
53 
fe 


April 2019 


(1.2.840.10045.4.3.2) 


(1.2.840.10045.2.1) 
(1.2. 


840.10045.3.1.7) 


2 40 uS GM Vd 
la HZ.-qReoée Qiu. 
02 eee PAC 1. x. 
6f ..0...N0U..o 
e (ees EEN 


(2.5.29.17) 


0...sip:bobQGe 
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10045.4.3.2) 


9e 
30 
£0 
Af 


E9 lu» s gs 
34 E ME o EE 04 
85 
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digestAlgorithm: 
algorithm: sha256 (2.16.840.1.101.3.4.2.1) 
parameter: <ABSENT> 
signedAttrs: 
object: contentType (1.2.840.113549.1.9.3) 
set: 
OBJECT: pkcs7-data (1.2.840.113549.1.7.1) 


object: signingTime (1.2.840.113549.1.9.5) 
set: 
UTCTIME:Jan 24 23:52:56 2019 GMT 


object: messageDigest (1.2.840.113549.1.9.4) 
set: 
OCTET STRING: 
0000 - ef 77 8f c9 40 db e6 dc-25 76 f4 7a 59 .w..0...S9v.zY 
000d - 9b 31 26 19 5a 9f la 22-7a da f3 5f a2 Ob AS AS 
001a - 2c 05 Od 8d 19 5a du es 
signatureAlgorithm: 
algorithm: ecdsa-with-SHA256 (1.2.840.10045.4.3.2) 
parameter: «ABSENT» 


signature: 
0000 - 30 45 02 21 00 £7 88 ed-44 6a b7 Of ff 2c 1f QE es se Dance pes 
000f - fa 4c 03 74 fd 08 77 fd-61 ee 91 7c 31 45 b3 ME E | LES 
001e - 89 a6 76 15 c7 46 fa 02-20 77 94 ad c5 7f 00 eo aides Et oe: Wigs 
002d - 61 c7 84 b9 61 23 cc 6e-54 bb 82 82 65 b6 d4 a...ad.nT...e.. 
003c - cc 12 99 76 a6 bl fc 6d-bc 28 d6 eee Mee eis: t. 

unsignedAttrs: 

<ABSENT> 


Figure 7: Message Signed by Bob prior to Encryption 
A.3.2. Encrypted Message 


CMS ContentInfo: 
contentType: pkcs7-authEnvelopedData (1.2.840.113549.1.9.16.1.23) 
d.authEnvelopedData: 
version: 0 
originatorInfo: «ABSENT» 
recipientInfos: 
d.ktri: 
version: «ABSENT» 
d.issuerAndSerialNumber: 
issuer: O=example.com, CN-Alice 
serialNumber: 9508519069068149774 
keyEncryptionAlgorithm: 
algorithm: rsaEncryption (1.2.840.113549.1.1.1) 
parameter: NULL 
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fl af-24 66 80 
b9 e4-54 84 b6 
fb 35-57 1a 56 
da 80-fb 73 10 
04 24-d9 33 05 
ad 95-07 2f 71 
Oc cc-5d d5 4b 
1a 68-de 10 62 
78 9a-88 37 77 
52 85-ca c6 a2 
6e Of-f3 7e 2c 
el c7-48 96 3b 
9d d5-c7 58 3e 
22 c3-7c 9a 76 
ac 98-47 4d 1e 
08 a2-18 d6 af 
fe b3-f1 81 41 
aa 86-51 37 el 
90 ba-79 e6 d7 
0b-7d 6f 78 
fe 59-5f 11 49 
7e 6f-76 a8 d9 
03 dc-ce 2f 1f 
f9 3d-8e 1c bf 
b8 f5-80 f1 14 
a7 64-b7 f8 c5 
b8 ad-63 c0 51 
ea 22-62 41 3f 
e8 el-a4 8c ad 
20 e0-5c ca 06 
59 b9-f0 £7 da 
8c 8b-5d ba ca 
e5 eb-b4 67 79 
07 98-9b 88 9b 


3b 


gom 
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encryptedKey: 
0000 - 75 9a 61 b4 dd fl 
000f - 61 10 fa 27 23 c1 
001e - de 96 7d c5 eO ca 
002d - 50 e7 be 31 cl 31 
003c - b8 d6 4c ac 26 04 
004b - 94 15 dd 64 4b 3c 
005a - 9f 28 2c 48 83 bd 
0069 - 0a Ge 55 e5 92 c5 
0078 - ca 8e 76 4b b8 ac 
0087 - 6c Oa Ge d3 ec ae 
0096 - 57 19 al bd cf 90 
00a5 - 62 25 10 Oc cO 62 
00b4 - df cf 71 40 73 72 
00c3 - 18 6f 2f a4 17 be 
00d2 - aa d2 7f 73 ae 44 
00e1 - 12 a4 03 d0 b3 ce 
00f0 - 7c c5 c9 66 4f 6d 
ooff - 84 09 Oa a6 03 80 
010e - 97 41 67 9d 7a 3c 
Olld - b5 4a 66 74 23 ei 
012c - be 34 36 62 a6 35 
013b - c2 eO ba 31 8c 22 
014a - d3 ea 1c 8e ce a0 
0159 - 33 5d el 30 3f cb 
0168 - eb 62 4b ac dl di 
0177 - 94 fb 40 44 ab da 
0186 - 52 b3 5a eb 96 39 
0195 - £8 23 c2 20 10 67 
01a4 - £7 b6 14 3f 84 2a 
0153 - a3 cf 9e e7 e3 66 
Olc2 - ee fl a4 98 f2 d2 
Oldl - 06 1f 38 7c 2d c4 
OleO - 2f 47 92 51 65 c9 
Olef - d6 97 b4 47 f4 c4 
Olfe - af 78 

authEncryptedContentInfo: 
contentType: pkcs7-data 
contentEncryptionAlgorithm: 
algorithm: aes-128- 
parameter: 


aes-nonce: 
0000- 4d 87 57 22 2e ac 
aes-ICVlen: 16 
encryptedContent: 
0000 - fe 2f b3 de Ob CU 
000f - 8b Of ee 3d 7e 2e 
001e - de cd 94 04 88 56 
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69 98-c3 9b f4 
85 18-1a ec fl 
12 df-c6 98 43 
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05 63 5e 47 
d3 3e 83 87 
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24 84 5b ab 
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65 ef 8d c3 
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45 69 24 89 
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69 9c 5c 81 
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c0 b4 ab 67 
c5 39 50 ca 
40 40 Of d3 
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d6 82 f1 9b 
al 3b 89 08 
ff 92 94 94 
5c 95 cc c6 
ef 39 7d 48 
3a e0 la ba 
11 bf ac 00 
83 ef 6f 1b 
86 23 08 £3 
98 84 91 8d 
Oc 2e 95 80 


(1.2.840.113549.1.7.1) 


(2.16.840.1.101.3.4.1.6) 


12 
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002d 
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O2fd - 21 93 el 86 d4 
030c - 79 2f 3c fe b9 
031b - 1c cc 9c cd e2 
032a - 85 b7 a7 a2 bc 
0339 - Ge 9d Ya 40 £3 
0348 - dé 01 4b df 30 
0357 - d8 c0 ba d3 5d 
0366 - 10 28 84 5f 80 
0375 - bf 31 af 5a fc 
0384 - 88 64 8c 3e ef 
0393 - dd cb e2 6d 71 
03a2 - 33 76 ee 8c 68 
03b1 - 8f 4d £3 06 fe 
03c0 - 67 cd 76 6c £0 
03cf - f1 f8 82 33 f1 
03de - Od 21 e7 9f fc 
03ed - 78 2d 6d 6d 07 
O3fc - d7 5c 89 c0 b4 
040b - 3b 38 99 a5 39 
041a - 8d 19 6c 5c ed 
0429 - c5 09 5b 48 da 
0438 - c3 09 8e 86 Ae 
0447 - 94 7b 5e ea 77 
0456. — E: £1 32 55-96 
0465 - d2 94 21 21 08 
0474 - 6b ca 98 81 b6 
0483 - 5d 67 92 c6 88 
0492 - d6 98 d6 89 56 
04al - 6d 14 89 00 c7 
04b0 - d4 f1 00 60 ff 
O4bf - dd 05 7e d3 ei 
O4ce - £9 Ob 75 1d Ga 
04dd - 3e a8 db 
authAttrs: 
<EMPTY> 
mac: 
0000 - £6 ff c6 el ae 
000f - 2d 
unauthAttrs: 
<EMPTY> 
Figure 8: 


Campbell & Housley 


S/MIME 


43 
bb 
b8 
ae 
20 
a6 
df 
89 
8c 
el 
24 
10 
74 
7b 
16 
98 
87 
26 
d9 
69 
7a 
Oc 
£7 
23 
6c 
95 
24 
11 
4c 
fe 
Oe 
la 


f1 


58 
de 
8c 
c7 
46 
Of 
19 
54 
2b 
47 
c6 
95 
7f 
45 
al 
27 
16 
3b 
a3 
7b 
5b 
e7 
a6 
43 
df 
08 
09 
87 
16 
5e 
be 
df 


9c 


for SIP Messaging 


de-38 
72-11 
d8-37 
52-e6 
2c-5d 
75-fc 
84-f2 
3d-f4 
70-8d 
65-15 
el-d9 
68-e8 
37-11 
Oc-bf 
a7-f3 
22-1b 
76-f7 
f1-0f 
ac-5b 
2e-d8 
03-b4 
d4-67 
be-16 
21-7b 
al-96 
29-64 
41-4d 
13-a0 
92-1d 
36-bb 
d6-90 
a0-59 


d2-3d 


8d 
d2 
37 
7 
66 
06 
24 
f1 
50 
8f 
92 
Duk 
75 
62 
ca 
68 
98 
56 
e2 
03 
7e 
da 
c8 
9c 
58 
f1 
70 
ff 
f9 
ba 
83 
Od 


98 


73 
6f 
T3 
d6 
f8 
3d 
le 
44 
b6 
bO 
f8 
Tf 
14 
ca 
f1 
bO 
94 
24 
b6 
b9 
2b 
99 
c7 
29 
19 
2e 
33 
12 
b3 
ca 
£9 
b1 


5a 


Message Encrypted 


21 
56 
ea 
e0 
35 
c9 
d3 
le 
45 
e8 
32 
Oc 
8f 
d2 
2f 
80 
3e 
3f 
94 
87 
9f 
cd 
e9 
50 
5b 
7c 
21 
72 
8f 
£2 
d3 
9d 


92 


by 


Standards Track 


1b 
ab 
Ee 
le 
17 
20 
b5 
de 
d4 
d3 
30 
9b 
31 
a7 
34 
ff 
54 
9e 
00 
ab 
e4 
"7f 
e0 
38 
e6 
f8 
ec 
ac 
29 
di 
a2 
al 


19 


a2 
06 
37 
02 
16 
84 
29 
36 
e7 
bb 
aa 
bd 
83 
bd 
be 
03 
f1 
72 
a3 
ee 
cd 
3a 
de 
6e 
d7 
01 
83 
bc 
ec 
ba 
a2 
07 


76 


f1 
el 
fd 
b8 
dc 
5e 
dc 
bl 
db 
53 
95 
a4 
27 
71 
£4 
ad 
3f 
ef 
cf 
85 
4b 
9e 
cc 
85 
£8 
02 
ab 
9a 
46 
d7 
6e 
cf 


35 


April 2019 


E NEo cni d EA 
..2U.4Cl!(.)P8n. 
E EE Moles 


Bob for Alice 


[Page 38] 


RFC 8591 


Authors’ Addresses 


Ben Campbell 


Standard Velocity, LLC 


Email: ben@nostrum.com 


Russ 
Vigil 


Housley 
| Security, LLC 
housley@vigilsec. 


Email: 


Campbell & Housley 


S/MIME for SIP Messaging 


com 


Standards Track 


April 2019 


[Page 39] 


